Rapid, Trace-Driven Simulation of the Performance of Web Caching Proxies

We have designed and validated a rapid, accurate simulation method for evaluating the performance of Web proxy cache replacement algorithm designs. We model the client-proxy-server system by combining a linear model of client-proxy response times with real measurements of proxy-server response times. We experimentally validate the model’s accuracy on the Apache proxy server. Our method should be employed to compare alternative designs for replacement algorithms. Introduction Both Intranets and Internet backbones—such as AOL, Prodigy and @Home—use Web caching proxy servers to improve performance. Many workers (Abrams et al. (1995), Aggarval et al. (1996), Bolot and Hoschka (1996), Scheuermann et al. (1997), Wooster and Abrams (1997)) recognize that performance-based cache replacement algorithms (RAs) can speed up Web proxies, with respect to traditional measures such as LRU. We contribute a validated non-queuing performance model of client-proxy-server systems, developed from first principles. Bolot and Hoschka (1996) model proxy behavior, but do not include client-LANproxy or proxy-WAN-server details. We believe our model will provide a useful basis for the design of future RAs. We contribute a simulation method that speeds up the evaluation of new cache designs, since directly measuring the performance of an operating cache can take too long to repeat multiple times in a design process. Assume a client program issues a test sequence of requests to a proxy server whose cache contains 500 MB. Running four cache sizes of documents in order to obtain statistically significant results requires that the client program request 2 GB of documents. If the proxy receives an average of R Kbps then an experiment must run for hours 600 , 5 Kbps GB 2 R R = Typical values of R range from 10 to 1,000 so a single proxy performance run would take between 5 and 500 hours. For example, Wooster and Abrams (1997) ran proxy tests for 250 hours. To compare the performance of cache designs, a designer would redo this experiment with multiple traces, multiple RAs and multiple implementations of the proxy server. The designer would want to vary other parameters, such as times of day. To avoid experiments that take many days or weeks, we have designed a simulation methodology that evaluates cache RAs much more rapidly. Accurate Simulation of Proxy Performance We obtain accurate inputs for our simulations, as described in the following steps. 1 Submitted to the Workshop on Internet Server Performance. 2 This work has been supported by an IBM Partnership Award. Web cache simulation 2 1. Model the performance of the client, LAN and proxy interaction: Determine performance characteristics of the caching proxy. 2. Obtain proxy trace: Obtain a proxy trace and remove outdated references. 3. Trace performance of WAN and servers: Send the sequence of requests in the trace over the WAN directly to the servers, and record the performance and metadata content of the responses. The inputs gathered in steps 2 and 3 drive a simulation of a cache receiving the trace. The simulation— pure computation—runs quickly. It uses a theoretical model for client-proxy-server communication derived from the parameters collected in step 1. The next two sections of the paper describe and validate such a theoretical model. Model for Client-Proxy-Server Communication We formulate a rigorous mathematical framework for client-proxy-server communication, based on two concepts: • We treat the proxy as a black box and specify only the observable communication performance characteristics that it can use in its decision making. • Any caching scheme depends fundamentally on locality of access: the probability that a particular object A is accessed may depend on the recent access history. We introduce conditional probabilities indirectly, by fixing an access sequence W out of all of possible sequences. This approach has the following advantages: • Theory and implementation share the same formalism. Proxy algorithms trying to optimize performance measures based on observables can be specified and analyzed within this formalism. • It naturally leads to the simulation method for testing proxy implementations. Given W, multiple candidate proxy algorithms can be efficiently compared with each other under repeatable laboratory conditions. Access sequences Let OBJ be the set of all persistent, cacheable objects accessible on the network (which can be the WWW or an Intranet). By wn : [1,n] → OBJ we denote an access sequence of length n of objects in OBJ in which objects are retrieved more than once: we expect wi = wj to hold for many i ≠ j. The set of all access sequences is defined as W = {wn | n ∈ μ and wn : [1,n] → OBJ}. Convention. Instead of wn we say w is an access sequence of length n. Instead of w (1), ..., w(n) we write W1, ..., Wn. The Wi’s denote objects on the network of unspecified content. So far, w merely specifies the order in which its objects are accessed. Proxy performance evaluation, however, is based on observable physical quantities, among which we identify access time, object size, access latency, network bandwidth and computation time. We will now define these terms. Observable object attributes Three actors are involved in our scenario: the client, the proxy and a Wide Area Network connected to servers, which we will treat as a single entity and simply refer to as the WAN. We now present a model in which no pipelining takes place (i.e., the proxy waits until the entire object has been received from the server before it forwards it to the client). Later, we will present a slight modification of the model which allows pipelining. For Wi e w, let the corresponding object have size Si. The following events, illustrated in Figure 1, take place if Wi is not in the proxy’s cache (we omit the subscript i for readability): • At local client time TC1, the client sends the first byte of its request message. • At local client time TC2, the client sends the last byte of its request message. • At local proxy time TP1, the proxy receives the last byte of the request message. • At local proxy time TP2, the proxy connects to the server. 3 We find that about 3⁄4 of the references are good in a week old trace from a major ISP. Web cache simulation 3 • At local proxy time TP3, the proxy sends the last byte of the request message to the server. • At local proxy time TP4, the proxy receives the first byte of the response from the server. • At local proxy time TP5, the proxy sends the first byte of the object to the client. • At local proxy time TP6, the proxy receives the last byte of the response. • At local client time TC3, the client receives the first byte of the response. • At local proxy time TP7, the proxy sends the last byte of the response. • At local client time TC4, the client receives the last byte of the response. Note that client and proxy clocks do not need to be synchronized.